1. Field of the Invention
The present invention relates to the fields of distributed computing systems, client-server computing and object oriented programming.
2. Background
A computer programmer writes a program, the source program, in a high level language which typically makes use of symbols for addresses, and special characters or acronyms for operation codes. This source code comprises a set of instructions for the computer and data with which or upon which the instructions are to operate. These instructions and data must be loaded into a computer's memory at certain addresses in order for the computer to execute the program process. In order to make this happen, the source code is processed by a compiler which generates binary object code which a computer can execute. Before the computer can execute this newly written program, the program must go through several additional steps, during which the addresses in the program may be represented in different ways. The compiler typically will bind the symbolic addresses of the source code to relocatable addresses (such as 16 bytes from the beginning address of the program). A linkage editor or loader will in turn bind these relocatable addresses to absolute addresses (such as memory location 64216). Each binding is a mapping from one address space to another. This binding of instructions and data to memory addresses can be done either at compilation time, load time or at program execution time.
Referring to FIG. 1, the several steps described above are depicted. The source program 1 is processed by a compiler 2 producing an object code module 3. This object code module 3, generally along with other previously compiled object modules 4, is processed by a linkage editor 5 to produce a load module 6. The load module 6 and any system libraries 7 required are processed by a loader 8 producing an in-memory binary image 10 of the original program and its related modules and libraries. This in-memory binary image 10 can now be executed by the computer.
Continuing to refer to FIG. 1, when it is known at compile time 12 where the program will reside in memory, these programs are compiled with absolute code for addresses. In most cases however, it is not known at compile time where the program will reside in memory, and the compiler must generate relocatable code for the memory addresses. In this case, final binding of memory locations to the addresses is delayed until either load time 13 or execute time 14. Some modern systems delay such address binding until execute time 14 when the program image can be moved during its execution from one memory segment to another or where the program start-up cost is not excessive because the program images contain few relocatable addresses, such as with position independent code (PIC). PIC is code generated by some compilers which can be placed anywhere in memory because all memory references are made relative to the program counter.
Modern computer operating systems are designed to optimize the use of memory space and to minimize user wait time. This is done in the address binding/program loading process, by dynamic loading of program object modules only when they are actually called by another module and dynamic linking of an object module to its system library routines only when they are required. In these cases the main program is loaded into memory and executed and supporting object modules or system libraries are not loaded unless they are called by the main program, thus saving memory space and load time at the expense of some program start-up time. Also, system libraries which will likely already be resident in memory can be dynamically linked to the executing main program when called, thereby not requiting a copy of the system libraries to be linked and loaded with each main program at load time, again saving memory space but at the cost of some program start-up time and some execution time. With dynamic linking, a stub is included in the image for each library-routine reference. This stub is a small piece of code that indicates how to locate the appropriate memory-resident library routine. When the stub is executed it replaces itself with the address of the routine and executes the routine. Under this scheme all programs that use a library routine use the same copy of the library code.
In order to take maximum advantage of dynamic linking and loading, program compilers must be designed to produce the necessary relocatable address references, the sub-routine stub code, and efficient PIC code. Unfortunately, existing compilers for object-oriented program modules cannot generate such code efficiently. For example, the cfront 3.0 preprocessor and the G++ compiler generate virtual function tables as initialized data structures which are full of references to relocatable symbols. Thus the number of relocatable symbols in object-oriented program modules is much higher than in more traditional program modules and the program startup delay required to dynamically link these modules can rise to unacceptable levels due to the number of relocations. Therefore what is required is a system that provides efficient dynamic linking of program modules with large numbers of relocatable symbols.
The present invention provides an elegant solution to this problem by caching linked program images and also caching partially linked library programs.